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ABSTRACT 


This  lepon  concentrates  on  implementation  issues  associated  with  the  security 
model  for  object-oriented  databases  introduced  by  Jajodia  and  Kogan  [4J.  The 
discussion  of  the  model  is  conducted  from  the  implementation  point  of  view. 
Wc  argue  that,  due  to  certain  characteristics  that  our  model  possesses,  its 
implementation  turns  out  to  be  a  conceptually  simple  matter.  We  analyze  two 
alternative  approaches  to  the  subject  of  implementation.  Finally,  we  explicate 
the  requirements  that  our  model  places  on  the  implementation  of  tlie  object 
layer. 
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1,  Introduction. 

This  report  concenti'atcs  on  implementation  issues  associated  with  the  security 
model  for  object-oriented  databases  introduced  by  Jajodia  and  Kogan  [4],  The  single 
most  important  point  that  we  will  try  to  make  here  is  that  the  nature  of  our  model  is  sucli 
that  it  already  contains  the  recipes  for  implementation.  In  other  words,  it  would  be  wise 
to  consider  the  questions  of  the  model  and  its  implementation  in  a  highly  integrated  way 
rather  than  to  place  them  at  related  but  separate  conceptual  levels. 

Because  of  the  preceding  consideration  we  think  it  advisable  to  start  this  report  with 
a  brief  but  self-contained  description  of  the  model  of  [4]. 

The  main  motivation  of  our  work  in  [4J  was  to  construct  a  security  model  that 
would  integrate  in  a  very  natural  way  with  an  object-oriented  model  rather  than  juxta¬ 
pose  with  it.  To  that  end  we  decided  to  move  away  from  the  traditional  object-subject 
paradigm  of  Bell  and  LaPadula  [2]  for  multilevel  security.  In  its  place  we  introduced  a 
new  paradigm  whose  main  elements  were  objects  (in  the  new,  object-oriented  sense)  and 
messages. 

In  an  object-oriented  data  model,  the  notion  of  object  is  rather  different  from  the 
Bell-LaPadula  notion  of  object.  Whereas  the  latter  is  simply  a  file,  or  a  record,  or  a  field, 
the  fomier  can  be  regarded  as  a  passive  repository  of  data  and,  at  the  same  time,  as  an 
active  agent  manipulating  those  data  and  communicating  with  other  objects.  It  seems 
natural,  therefore,  that  such  objects  be  viewed  as  units  of  security.  Perhaps  the  most 
imponant  consequence  of  adopting  such  a  view  is  that,  due  to  the  property  of  encapsula¬ 
tion,^  infomiation  flow  becomes  explicit  (in  the  fonn  of  message  exchange  among 

^  Encapsulation  of  objects  —  a  fundamental  properly  of  object-oriented  systems  —  means  that 
only  objects  themselves  can  have  direct  access  to  their  internal  state  (llieir  atiribiilcs).  l\)r  anyone 
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objecls)  and,  therefore,  easy  to  control.  Thus,  the  notion  of  encapsulation,  which  was  ori¬ 
ginally  introduced  in  object-oriented  systems  to  facilitate  modular  design,  can  now  be 
employed  for  purposes  of  security.  The  conceptual  clarity  and  simplicity  of  the  model 
translates  into  simplicity  of  design  of  security  mechanisms. 

An  informal  view  of  the  model  describes  the  system  as  consi  ;ting  of  objects  that  are 
assigned  unique  security  classifications.  Objects  can  communicate  among  themselves 
only  by  means  of  sending  messages.  Messages  cannot,  however,  flow  directly  from  one 
object  to  another.  Instead,  they  have  to  be  screened  by  a  security  module  that  decides 
how  to  handle  any  given  message  based  on  the  security  classifications  of  the  sender  and 
the  intended  receiver  as  well  as  some  additional  information.  The  rulings  issued  by  this 
module  embody  the  security  policy. 

Section  2  is  reproduced  from  [4].  In  it,  we  define  our  formal  object-oriented  data 
model.  Section  3  is  an  exposition  of  the  security  model  rendered  in  such  a  fashion  as  to 
address  implementation  concerns  more  explicitly  than  it  was  done  in  [4j.  Section  4 
explains  why  our  model  is  conceptually  easy  to  implement  in  object-oriented  environ¬ 
ments.  Section  5  discusses  some  alternatives  for  implementation  of  object-oriented  data¬ 
bases  based  on  our  model,  particularly  the  issue  of  which  elements  of  the  system  have  to 
be  trusted.  Section  6  addresses  some  requirements  placed  by  our  model  on  the  imple¬ 
mentation  of  the  object  layer.  Finally,  Section  7  ends  this  report  with  .some  concluding 
remarks  and  observations. 


else  to  access  the  object’s  state,  it  is  necessary  to  send  a  message  to  that  object. 


2.  Object-Oriented  Data  Model. 


An  object-oriented  database  is  a  collection  of  objects  communicating  via  nicssai^es. 
Each  object  consists  of  a  unique  identilicr,  a  set  of  attributes  and  a  set  of  mcihods,  ilic 
latter  being  essentially  pieces  of  code.  Each  attribute  has  a  value,  which  can  cliangc  over 
time. 

An  object  can  invoke  one  of  its  methods  in  response  to  a  message  received  fiom 
another  object.  A  method  invocation  can,  in  turn,  (1)  directly  access  an  attribuie  belong¬ 
ing  to  the  object  (read  or  change  its  value);  (2)  invoke  other  methods  belonging  to  the 
object;  (3)  send  a  message  to  another  object;  or  (4)  create  a  new  object. 

There  is  a  special  type  of  object,  called  user  object.  A  user  object  represents  a  user 
session  with  the  system,  user  objects  differ  from  regular  objects  in  that,  in  addition  to 
being  able  to  invoke  methods  in  response  to  messages,  they  can  also  invoke  methods 
spontaneously.^  User  object  can  be  created  only  by  the  system,  at  the  login  time. 

Let  us  formalize  now  the  central  elements  of  the  object-oriented  data  model.  We 
postulate  a  finite  set  of  domains  D  j ,  D2,  ...,  D^-  Let  D  be  the  union  of  the  domains  aug¬ 
mented  with  a  special  element  nil,  i.e.,  D  =  D  i  Dikj  •  co  (nil}.  Every  ele¬ 
ment  of  D  is  referred  to  as  a  primitive  object.  Let  A  be  a  set  of  symbols  called  attribuie 


4. 

Tire  notion  of  spontaneous  method  invocation  may  seem  rather  arbitrary  at  first.  It  is,  Iiowcvcr, 
ncccs.san'  in  order  to  avoid  running  into  a  version  of  the  chickcn-and-cgg  paradox.  Namely,  if  a 
message  can  be  sent  only  tlirough  a  method  invocation  (see  pro[)crly  (3)  of  method  invocations) 
and  if  a  mctltod  can  be  activated  only  by  a  message  received  from  another  object,  then  how  docs 
any  processing  in  such  a  system  ever  get  initiated?  (One  has  to  insist  that  cither  the  egg  or  the 
chicken  come  first.)  In  reality,  we  want  a  user  to  be  able  to  initiate  a  system  activity,  c.g.,  by 
tyiiing  a  string  of  characters  on  the  keyboard.  This  would  serve  as  a  signal  for  tlic  corresponding 
u.scr  object  to  initiate  a  mctltod.  We  choose  to  think  of  this  as  a  "spontaneous"  initiation,  because 
the  kcylward  and  any  signals  that  it  sends  ate  external  to  our  model. 


\ 
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names,  1  a  set  of  identifiers,  and  M  a  set  of  finite  strings  of  code  called  methods.  Let  be 
a  set  of  values  defined  as  follows:  V  =  D  u  /  That  is,  a  value  is  either  a  primiiivc 
object  or  an  identifier  or  a  set  of  identifiers. 


Dermitiun  1.  An  object  is  either  a  primitive  object  or  a  quadruple  <'>  =  (,  i,  a,  v,  p) 

such  that  i  e  1,  a  =  (ai,  ...,  ah)  where  aj  e  A  for  all  y  (1  <  y  <  ^),  v  =  (  v  . . v^)  where 

Vj  e  V  for  all  y  (1  <  y  <  k),  and  p.  c  M.  □ 


Definition  1  states  that  an  object  is  defined  by  its  identifier,  an  ordered  set  of  attri¬ 
bute  names,  an  ordered  set  of  corresponding  values,  and  a  set  of  methods.  We  assume 
that  every  object  has  a  unique  identifier,  i.e.,  for  any  two  objects  =  ( i^,  a^.,  Vy,  p_y)  and 
ot  =  ( it,  at,  Vt,  p,),  Ov  =  Ot  iff  is  -  it-  The  uniqueness  of  object  identity  is  commonly 


wv/i  4  W  *  v«i  *4jli44  i  4  wii  V/ 4  V/A  4  Vt  i  0^>JVV44  4^  L  J  * 


We  will  use  the  following  notation  in  the  foregoing  discussion.  Let 
Os  =  (is,  Us,  Vs,  p.v)  be  an  object.  Then  i{Os)  denotes  the  object  identifier,  aios) 
denotes  the  list  of  attributes,  riy;  vf  <'>.v)  denotes  the  list  of  attribute  values,  Vy,  and  p(  r>,y) 
denotes  the  object’s  set  of  methods,  p^. 


Definition  2.  A  message  is  a  triple  g  =  {h,  p,  r)  where  h  is  the  message  name, 
P  -  {P\y  •••>  Pk)y  k  >0,  is  an  ordered  set  (list)  of  values  called  the  message  parameters, 
and  r  is  the  return  value.  □ 


Similarly  to  the  notation  used  for  objects,  we  let  fi{  g),  p{  g),  and  r{g)  denote  tlie 
name,  the  parameter  list,  and  the  return  value  of  message  g  rc.spcctively. 


An  object  .sends  a  mes.sage  by  invoking  a  system  primitive  SEND  ( g,  i)  wlicre  i  is 
the  identifier  of  the  receiver  object.  The  value  r(  j,»)  is  computed  by  the  method  activated 
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j. 

in  the  receiver  upon  the  arrival  of  there  and  returned  to  the  sender. ' 

In  the  literature  on  object-oriented  data  models,  the  response  to  a  message  is  often 
defined  as  a  return  object.  We  use  the  notion  of  variable  instead,  in  order  to  avoid  deal¬ 
ing  with  the  issue  of  accessing  the  state  of  the  return  object,  which,  in  compliance  with 
tlie  property  of  encapsulation,  would  have  to  be  done  via  message  sending  (unless  the 
return  object  is  a  primitive  object).  Sending  messages  to  an  object  that  has  been  returned 
in  response  to  another  message  seems  conceptually  cumbersome.  The  notion  of  variable, 
on  the  other  hand,  implies  direct  accessibility  without  the  need  to  resort  to  message  send¬ 
ing.  Of  course,  return  variables  should  be  allowed  to  have  arbitrarily  complex  structure 
if  we  do  not  want  to  lose  the  modeling  power  associated  with  objects. 

Deflnition  3.  The  interface  fo  of  object  <?  is  a  function  fo'.H  \i{o)  u  {void} 
where  H  isa.  set  of  all  possible  message  names.  □ 

The  interface  of  object  o  determines  which  messages  o  responds  to.  Those  are  the 
messages  whose  names,  li,  are  such  that  f(,{h)^void.  If  fo{h)  =  void,  o  does  not 
respond  to  messages  w'hose  name  is  h.  Moreover,  the  interface  detemiincs  which  partic¬ 
ular  method,  out  of  the  set  of  methods,  }J(o),  defined  for  object  o,  is  to  be  invoked, 
depending  on  the  name  of  the  given  message. 

We  have  defined  methods  as  strings  of  code.  Now  we  are  in  a  position  to  give  a 
more  fomial  definition  of  methods. 

^  As  wc  .shall  see  in  llie  next  section,  sometimes  the  security  component  of  tlic  system  will  have 
to  interfere  in  the  matter  of  computing  r  (  g). 


Definition  4.  Let  o  be  an  object.  A  method  m  defined  for  o  {m  e  )i)  is  a  function 
m:  P  X  2^  X  V  where  P  is  a  set  of  all  possible  paraineter  lists.  □ 

Definition  4  states  that  a  method  maps  a  list  of  parameters  into  a  triple.  I'he  first  ele¬ 
ment  of  the  triple  is  a  set  (possibly  empty)  of  attribute-name — attribute -value  pairs  where 
the  names  are  drawn  from  the  set  of  the  object’s  attribute  names.  The  second  element  is 
a  set  (possibly  empty)  of  message — identifier  pairs.  The  third  element  is  a  value. 

In  response  to  a  message  g  -  {h,  p,  r),  an  object  o  invokes  a  method  m  e  p(  r>) 
such  that  m  =  /,(  h)  (we  assume  that  fo{  h)  ^  void).  Then,  the  value  tn{p)  is  computed 
(this  corresponds  to  executing  the  method’s  c  >de  with  the  argument  list  p).  The  compu¬ 
tation  results  in  w ( p)  =  (  f  (  a i ,  v ^ ),  ...,  (  a„  v,)},  {(gu  ii),  ...,  ( g,,  it)},  vj).  The 
semantics  of  this  are  as  follows.  Attributes  dj, ...,  of  o  are  updated  with  new  values 
V  j ,  ...,  respectively;  messages  g  i ,  ...,  g,  are  sent  to  the  objects  with  identifiers  i  j ,  ....  tj 
respectively;  and  vy  is  returned  to  the  sender  of  g.  Note  that  for  some  k  we  could  have 
4  =  i-e.,  an  object  can  send  a  message  to  itself.  This,  for  instance,  can  serve  as  a 

mechanism  for  invoking  other  methods  within  the  same  object. 

Objects  are  used  to  model  real-world  entities.^  This  is  done  by  associating  proper¬ 
ties,  or  facets,  of  an  entity  with  attributes  of  the  corre. spending  object.  The  attribute 
values  tu'e,  then,  instantiations  of  those  properties.  For  instance,  a  country  can  be 
represented  in  a  geographic  object-oriented  database  by  an  object  o  where  aio)  = 
(COUNTRY_NAME,  POPULATION,  CAPITAL,  NA'IIONALJ-LAG. 

FORM_OF_GOVERNMENT)  and  v  (  o)  =  (“Albania”,  i  17,  i  (  o  i ),  i ( (>2),  i (  03)).  The 
^  As  wc  will  see  later,  a  single  entity  may  be  modeled  by  more  than  one  objeet. 
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valucs  of  the  first  and  second  attributes  are  a  string  and  an  integer,  respectively;  the 
values  of  the  rest  of  the  attributes  are  references  to  other  objects  that,  in  turn,  describe  the 
capital,  the  national  flag,  and  the  fonn  of  government  of  the  nation  of  Albania. 

Note  that  an  object’s  methods,  unlike  its  attributes,  do  not  have  counterparts  in  the 
real-world  entity  modeled  by  the  object.  The  purpose  of  methods  is  quite  diflbrent.  It  is  to 
provide  support  for  basic  database  functionality  such  as  querying  and  updating  objects. 

A  realistic  object-oriented  model  should  also  contain  the  notion  of  constraints.  For 
instance,  an  attribute  of  an  object  may  be  allowed  to  assume  values  only  from  a  restricted 
subset  of  domains  or  object  identifiers.  To  simplify  the  exposition,  we  choose  to  disre¬ 
gard  the  issue  of  constraints  in  this  report.  However,  it  should  be  a  simple  matter  to  incor¬ 
porate  this  notion  in  our  security — data  model. 

3.  Object-Oriented  Security  Model. 

The  system  consists  of  a  set  O  of  objects  (see  Definition  1)  and  a  partially  ordered 
set  S  of  security  levels  with  ordering  relation  <.  A  level  S,  e  5  is  said  to  be  dnminaied  by 
another  level  Sj  e  S,  this  being  denoted  by  5,  <Sj,  if  i  =  j  or  5;  <  Sj.  For  two  levels  Si 
and  Sj  that  are  unordered  by  <,  we  write  S,  <>  Sj. 

There  is  a  total  function  L:  O  —^S,  called  security  classification  function,  i.c.,  for 
every  o  g  O,  L{o)  e  S.  In  other  words,  every  object  has  a  unique  security  level  associ¬ 
ated  with  it. 
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3.1.  Characterization  of  Infurmution  Flows. 

Infornutioii  can  Icf^aHy  flow  from  an  object  Oj  to  an  object  if  and  only  if 

1. 1,  <>y)  ^  Oil  All  olhci  infonnation  flows  arc  considered  ilU'gol. 

Ip.  |4J  we  identified  basic  types  t>f  information  flow'.  They  arc  as  follows:  forward, 
backward,  transilivc,  and  indirect  flow  s.  The  forward  flow  is  carrii'd  b\’  a  messaize  in  its 
parameter  list.  The  backward  flow  is  associated  with  a  message’s  return  value.  The  tran¬ 
sitive  flow  is  the  net  cflect  of  several  forward  or  backward  flows  along  a  chain  of  objects. 
1  he  indirect  flow  occurs  between  two  objects  that  do  not  exchange  messages  with  each 
other  but.  instead,  exchange  messages  with  a  third  object;  the  latter  is  not,  howesei, 
directl)  aflected  by  tlie  flow  (unlike  the  ease  of  the  transitive  flow  ). 

.As  aigucd  tn  Hj,  for  an  object  to  acquire  infonnation,  the  values  of  some  of  its 
attributes  must  Ix'  changed  Therefore,  one  can  prevent  an  illegal  forward  infonnation 
tlow  b>  milking  sure  that  no  such  changes  iKCur  as  a  result  of  a  method  invocation  in 
response  to  a  tncssage.  Similarly,  an  illegal  backward  flow  is  prevented  by  reliiining  nil 
in  tesponse  to  a  message.  Note  that  nil  is  also  returned  when  the  message  is  undeliver;ible 
for  whatever  reason  (e  g.,  the  target  object  dtx-s  not  exist).  Next,  by  definition,  if  no  ille¬ 
gal  fi>rward  or  Ixickwaid  flows  are  allowed,  no  illegal  transitive  flow  can  occur  either 
I  iiially,  to  present  illegal  indirect  infonnation  flows,  one  must  ensure  that  a  mettu>d  is 
ptesented  from  upd.iiing  any  Uxal  attributes  insiile  the  object  if  the  inetliod  is  insokeii  m 
resfUiPse  to  a  message  from  another  object  that  is  at  a  higher  or  unrelated  .security  level. 
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3,2.  The  Message  Filtering  Algorithm 

To  control  all  the  types  of  information  flow  described  above,  the  message  liliering 
algorithm  was  introduced  in  [4],  The  idea  that  information  flow  be  controlled  by  control¬ 
ling  the  flow  of  messages  requires  that  all  basic  object  activity  —  such  as  access  to  inter¬ 
nal  attributes,  new  object  creation,  and  invocation  of  local  methods  —  be  implemented 
by  allowing  an  object  to  send  messages  to  itself.^  These  are  built-in,  or  system-delined, 
messages.  This  means  that  a  response  to  such  a  message  is  carried  out  directly  by  tlie 
systems,  according  to  some  pre-detined  semantics,  rather  than  by  the  invocation  of  a 
user-defined  method. 

Por  easy  reference,  we  reproduce  here  the  message  filtering  algorithm  of  [4]  (see 
Pigure  1). 

In  I'igure  1,  g=(h,p,r)  is  a  message.  Objects  oj  =  ( /j,  aj,  Vj,  |ii)  and 
(>2  =  (/;.  ci2<  ^'2<  P2)  the  sender  and  the  receiver  of  g  respectively.  'I'he  method 
invocation  in  oj  responsible  for  sending  g  is  denoted  ij.  Pinally,  12  is  the  invocation  of 
the  method h)  in  02  after  receiving  g.  Every  method  invocation  t  has  a  siaius  .v(  r). 
'file  status  is  cither  U  (unrestricted)  or  R  (restricted).  The  default  is  U. 

The  message  filtering  algorithm  is  the  core  of  our  security  model.  Th.c  effect  of 

4 

making  this  security-modeling  choice  is  that  all  infonnation-transfer-related  activity  is 
rendered  explicit  in  the  fomi  of  message  sending.  This  has  a  direct  relation  to  the  ques¬ 
tion  of  implementation,  for  such  activity  is  now  subject  to  monitoring  by  a  security 

module  called  the  mcssa^’c  filter,  who.se  functionality  is  based  on  the  message  tilieiing 

^  llicrc  arc  cxislinj,  ohjccl-oricntal  ilauinasc  .sysicnis  ihat,  in  fact,  u.sc  tln.s  kind  ul 
implementation,  c.g.,  GcmSlonc. 


algorithm. 


4.  Algorithmic  Nature  of  the  Model. 

Our  security  model  has  one  distinctive  feature  that  makes  the  question  of  implemen¬ 
tation  relatively  easy  to  address.  That  is  the  fact  that  virtually  the  entire  model  can  be 
expressed  as  one  simple  algorithm.  When  coded  and  implanted  into  the  system  that  sup¬ 
ports  objects,  this  algorithm  becomes  a  security  module  that  we  refer  to  as  the  message 
filter.  The  role  of  this  module  is  to  act  as  an  interceptor  for  every  message  originated  by 
any  object  and  decide  how  to  process  that  message.  Figure  2  shows  the  interaction 
among  objects  as  taking  place  with  mediation  on  the  part  of  the  message  PUer. 

Thus,  the  model  already  contains  the  prescription  for  its  own  implementation.  This 
fact  is  due  to  the  model’s  algorithmic  nature.  Note  that  this  is  in  contrast  vrith  otlier 
existing  database  security  models,  which  are  constraint-based.  Models  of  the  latter  kind 
require  some  additional  work  on  mechanisms  for  enforcing  those  constraints  before  the 
actual  implementation  can  take  place.  In  addition,  those  models  probably  could  not  be 
implemented  as  a  single  module  because  the  constraint  checking  would  have  to  be  done 
in  a  number  of  different  logical  places. 

5.  Placement  of  Trust,  or  What  to  Rely  on. 

In  this  section,  we  discuss  what  is  perhaps  one  of  the  central  imj)lcmcntation  ques¬ 
tions  for  any  secure  system:  which  components  of  the  system  need  to  be  trusted. 
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CASE  A: 

Oi  ^02 

(1) 

ifL(oi)  ~L(o2) 

let  g  pass;  s(t2)<-s(r0 

(2) 

ifL(oi)  <>L{o2) 

block  g 

(3) 

ifL(oi)  <L{o2) 

let  g  pass;  r  nil;  ^  ( fi)  ^  ^  ^  i ) 

(4) 

\{L{02)<L{0y) 

let  g  pass;  s(:2)<-R 


CASE  B; 

0\  =  02 

(1) 

if /»  =  WRITE 

(l.a) 

=  U 

let  g  pass 

(l.b) 

if5{ri)  =  i? 

block  g 

(2) 

if  h=  READ 

let  g  pass 

(3) 

if  g  =  (  CREATl ,  /  vj,  ....  Sj} 

(3.a) 

if  j  ( r  1 )  =  f/  and  {Sj  <  L{oi)ov  Sj  <>  L{o\) 

let  g  block; 

(3.b) 

if5(/i)  =  ./? 

block  g 

(3.e) 

if  ,v  ( r  j )  =  C  and  L  ( i )  <  Sj 

let  g  pass 

(4) 

if  h  =  INVOKE 

let  g  pass;  s(t2)<-s(ti) 


Figure  1.  The  Message  Filtering  Algorithm. 


Figure  2. 


5.1.  The  TDI  Approach:  Complementing  the  Reference  Monitor  with 
the  Message  Filter. 

One  approach  to  this  question  is  dictated  by  the  traditional  notion  of  TDI  (Trusted 
Database  Implementation).  This  approach  relies  on  the  underlying  secuiity  kernel  of  the 
operating  system.  The  kernel  is  the  trusted  component  that  implements  the  mandatory 
access  control  in  the  context  of  multilevel  security.  The  role  of  the  database  security 
model  in  such  a  setting  is  to  provide  a  high  level  (data-modcl  level)  inn.  rpretation  of  the 
security  policy  for  database  users. 

In  accordance  with  this  approach,  the  central  element  of  our  model  —  the  message 


filter  —  does  not  have  to  be  trusted,  since  the  actual  security  enforcement  is  done  at  the 
operating  system  level  by  the  reference  monitor.  The  latter  checks  all  data  access 
requests  submitted  to  the  operating  system  by  user  processes  to  make  sure  that  no  viola¬ 
tions  of  the  access  policy  occur. 

The  TDI  approach  is  the  widely  used  way  of  dealing  with  database  security  require¬ 
ments.  Examples  are  the  SeaView  model  [1,3]  and  the  security  model  for  object- 
oriented  applications  developed  at  SRI  [6].  Our  security  model  can  be  just  as  easily 
implemented  using  the  TDI  approach  as  the  above  two.  In  this  implementation,  the  mes¬ 
sage  filter  would  provide  the  database  interpretation  for  the  actual  enforcement  of  the 
security  policy  by  the  reference  monitor.  The  reference  monitor  would  have  to  be 
trusted;  the  message  filter  would  not. 


5.2.  The  High  Level  Approach:  Replacing  the  Reference  Monitor  with 
the  Message  Filter. 


One  of  the  advantages  of  our  model,  however,  is  that  it  also  makes  possible  an  alter- 


iVAa  \Jk 


f  implementing  the  system  and  placing  tiust  among  its  coiuponeuis.  i  ms 


new  method  has  potential  advantages  over  the  more  traditional  one.  Below,  we  discuss 
these  advantages  following  the  discussion  of  why  the  alternative  method  is  feasible. 

But  first,  it  would  be  u.seful  to  compare  the  functionality  and  role  of  a  message  lilter 
with  those  of  a  reference  monitor.  There  is  an  interesting  parallel  between  the  two.  The 
function  of  both  is  to  control  infomiation-transfcr  activity  in  the  system,  based  on  tlie 
presumption  that  (1.)  all  such  activity  is  carried  out  using  a  predefined  set  of  primitives, 
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and  (2)  an  instance  of  usage  of  a  priniiiive  can  always  be  detected  and  acted  upon 
appropriately  by  the  seeurity  module  (a  message  filter  or  reference  monitor)  with  the 
objective  of  preventing  illegal  information  flows.  In  the  case  of  reference  monitor,  the 
primitives  are  data  access  requests  submitted  to  the  operating  system  by  an  active  process 
(usually  in  the  form  of  system  calls).  In  the  case  of  message  filter,  the  primitives  are  mes¬ 
sages  sent  by  method  invocations. 

The  majority  of  actual  computer  systems  today  are  implemented  using  data  access 
calls.  That  is  why  the  notion  of  reference  monitor  is  both  natural  and  effective. 

Imagine,  however,  that  messages  replaced  data  access  calls  as  the  basic  primitive. 
Then  it  would  be  just  as  natural  and  easy  to  guard  against  illegal  infomiation  transfer 
using  a  message  filter  as  it  was  using  a  reference  monitor  in  the  case  of  data  access  calls. 
Such  an  assumption  is  not  far  fetched  at  all  since  systems  exist  built  on  the  message  send¬ 
ing  primitive  [8]. 

Thus,  when  messages  replace  data  access  calls  as  primitives,  a  message  filter  should 
replace  a  reference  monitor  as  the  enforcer  of  security.  The  placement  of  trust,  then, 
shifts  from  the  latter  to  the  former,  i.e.,  the  former  must  now  be  trusted  and  the  latter 
disappears  completely.  Such  state  of  affairs  seems  quite  favorable  to  our  model  of  data¬ 
base  security  as  well  as  to  the  problem  of  secure  object-oriented  databases  in  general. 
The  reason  for  this  is  that  there  is  no  longer  a  separation  between  security  enforcement 
and  its  interpretation:  they  have  become  one  and  the  same.  The  rnessagj  filter  docs  noi 
rely  any  more  on  any  underlying  security  kernel  but  rather  enforces  security  directly  by 
regulating  the  flow  of  messages  among  objects.  This  situation,  wc  believe,  is  more 
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effective  and  reliable  than  a  two-tiered  implementation  of  the  kind  of  TDl. 

6.  Object  Security  and  Object  Implementation. 

In  order  for  our  approach  to  object  security  to  be  effective,  the  implementation  of 
objects  themselves  must  satisfy  certain  requirements.  In  other  words,  our  security  model 
is  not  indifferent  to  how  specifically  the  object  layer  is  implemented. 

This  subject  has  been  already  touched  at  several  points  earlier  in  this  repon  and 
especially  in  [4],  In  this  secuon,  the  subject  is  brought  into  focus  and  given  a  brief 
unified  treatment. 

All  such  implementation  requirements  imposed  by  the  security  model  can  be 
expressed  in  the  following  general  form:  Every  object  activity  related  to  information 
transfer  must  be  implemented  by  message-passing.  This  means  that  in  addition  to 
interaction  among  objects,  message-passing  must  also  be  used  for  the  following: 

(1)  reading  of  local  attributes  by  an  object, 

(2)  updating  of  local  attributes, 

(3 )  invocation  of  local  methods,  and 

(4)  inheritance  (both  class-instance  and  class-subclass). 

When  the  above  requirements  are  satisfied,  all  information  activity  in  the  system 
can  be  checked  directly  by  the  message  filter.  As  was  mentioned  in  [4],  some  existing 
object  oriented  systems  indeed  implement  access  to  local  attributes  and  local  method 
invocation  by  having  an  ooject  send  a  primitive  message  to  itself  The  situation  is  analo¬ 
gous  to  a  system  where  processes  have  to  issue  system  calls  in  order  to  access  data  or 
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activate  a  procedure.  Therefore,  there  is  nothing  unusual  about  these  requirements. 

Implementing  the  inheritance  mechanism  by  means  of  message  passing  is  not  a  new 
concept  either  (e.g.,  see  [7]).  Its  essence  is  in  redirecting  of  a  message  sent  to  an  object 
such  that  the  method  called  for  is  not  physically  located  in  the  object.  For  example,  al! 
the  methods  defined  for  a  class  of  objects  are  stored  within  the  class  object  for  that  class. 
Therefore,  when  a  message  is  sent  to  an  instance  of  that  class,  it  will  be  redirected  to  the 
class  object  so  that  the  needed  method  can  be  invoked  there.  Subsequently,  if  tlie  method 
invocation  requires  access  to  the  instance  object’s  attributes,  messages  will  be  sent  to  the 
latter  for  that  purpose.  A  further  redirection  of  messages  can  occur  if  the  method  in 
question  is  inherited  from  a  superclass  rather  than  defined  locally  for  the  class. 

Thus,  the  requirements  placed  by  our  security  model  on  the  implementation  of  the 
object  layer  are  by  no  means  unreasonable.  However,  the  very  fact  that  there  are  some 
requirements  will  preclude  using  our  model  with  just  any  object-oriented  database.  We 
do  not  consider  this  a  detriment,  though,  for  the  following  reason.  Our  interest  is  in  con¬ 
structing  an  effective  and  comprehensive  approach  to  security  for  object-oriented  data¬ 
bases,  not  just  coming  up  with  minimally  functional  mechanism.>  that  can  be  fitted  on  top 
of  any  existing  database. 

7.  Conclusions. 

We  have  attempted  to  present  here  an  integrated  treatment  of  the  questions  of  secu¬ 
rity  modeling  and  security  implementation  in  the  context  of  object-oriented  databases. 
Such  methodology  seems  particularly  appropriate  because  the  security  model  that  we  arc 


using  is,  by  its  very  nature,  both  abstract  and  implementation  specific. 

Perhaps,  the  most  important  novel  idea  found  in  this  report  is  that  of  supplementing, 
or  perhaps  even  replacing,  the  traditional  reference  monitor  with  the  message  filter, 
which  seems  to  be  a  natural  choice  in  object-oriented  databases. 

This  report  along  with  its  companion  report  on  the  object-oriented  data  and  security 
models  [4]  represent  an  initial  step  in  what  we  hope  will  be  a  long-term  research  effort 
towards  designing  and  building  multilevel  secure  object-oriented  databases. 
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sciences,  electromagnetics,  and  propagation,  and  electronic 
reliability /maintainability  and  compatibility. 
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